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Software To Secure Distributed Propulsion Simulations 

CORBASec brings role-based security to CORBA-object-wrapped simulations. 

John H. Glenn Research Center, Cleveland, Ohio 


Distributed-object computing systems 
are presented with many security 
threats, including network eavesdrop- 
ping, message tampering, and commu- 
nications middleware masquerading. 
NASA Glenn Research Center, and its in- 
dustry partners, has taken an active role 
in mitigating the security threats associ- 
ated with developing and operating 
their proprietary aerospace propulsion 
simulations. In particular, 
they are developing a collab- 
orative Common Object Re- 
quest Broker Architecture 
(CORBA) Security (COR- 
BASec) test bed to secure 
their distributed aerospace 
propulsion simulations. 

Glenn has been working 
with its aerospace propul- 
sion industry partners to de- 
ploy the Numerical Propul- 
sion System Simulation 
(NPSS) object-based tech- 
nology. NPSS is a program 
focused on reducing the 
cost and time in developing 
aerospace propulsion en- 
gines. 

NPSS has been developed 
by Glenn and sponsored by 
the NASA Ames Research 
Center. Glenn is an active 
domain member of the Object Manage- 
ment Group (OMG) — an open mem- 
bership, not-for-profit consortium that 
produces and manages computer indus- 
try specifications (i.e., CORBA) for in- 
teroperable enterprise applications. 
When NPSS is deployed, it will assemble 
a distributed-aerospace propulsion-sim- 
ulation scenario from proprietary analyt- 
ical CORBA servers and execute them 
with security afforded by the CORBASec 
implementation. 

The NPSS CORBASec test bed utilizes 
the Portable Object Adaptor (POA) ar- 
chitecture from the VisiBroker 4.x Ob- 
ject Request Broker (ORB) [Borland 
Software Corp., Scotts Valley, CA], and 
the Orbix 2000 ORB [IONA Technolo- 
gies, Dublin, Ireland, with U.S. head- 
quarters in Waltham, MA]. Quadrasis 
[Software Solutions Division of Hitachi 


Computer Products (America), Inc., 
Waltham, MA] integrated both VisiBro- 
ker 4.x and Orbix 2000 ORB architec- 
tures with their security service [Hitachi 
Security Service (HSS)]. The NPSS re- 
quired a security service that was com- 
patible with both ORBs. Glenn and two 
United States aeropropulsion-industry 
companies are the initial partners con- 
tributing to the NPSS CORBASec test 


bed. The test bed uses Security SecurlD 
[RSA Security Inc., Bedford, MA] two- 
factor, token-based authentication to- 
gether with HSS digital-certificate-based 
authentication to validate the various 
NPSS users. 

The CORBASec test bed was inte- 
grated across firewalls. The process of 
getting CORBASec to communicate 
across firewalls was a large accomplish- 
ment. Unlike processing Hypertext 
Transfer Protocol (HTTP) messaging, 
firewalls do not have designated ports 
for CORBA Internet Inter-ORB Protocol 
(HOP) traffic. NPSS also verified the 
CORBASec and firewall design by test- 
ing with multiple vendors’ firewalls. The 
OMG is now working on a Firewall Tra- 
versal specification that promises to pro- 
vide a standard solution to the COR- 
BASec firewall-integration problem. It 


will take some time before the CORBA 
and CORBASec vendors implement this 
standard solution. NPSS chose to move 
ahead with a workable solution. 

The CORBASec architecture is a flexi- 
ble ORB security architecture that sup- 
ports both security-unaware and secu- 
rity-aware application development. 
CORBASec security-unaware security 
features are primarily configuration- 


based, requiring very little programming 
and its security services are implicitly in- 
voked at the ORB interceptor layer. The 
CORBASec security-unaware architec- 
ture spares the application developer 
from having to write large amounts of se- 
curity code as the ORB interceptor layer 
has been configured to handle COR- 
BASec message traffic automatically. 
The CORBASec security-aware architec- 
ture is for applications that need 
fine-grain security. Security-aware appli- 
cations enforce fine-grain or applica- 
tion-specific security policies via the 
CORBASec application programming 
interface (API) explicitly invoked secu- 
rity services. Unlike security infrastruc- 
ture-based APIs such as the java. security 
package, the Java Cryptography Exten- 
sion (JCE), and the Java Authentication 
and Authorization Service (JAAS) , COR- 
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The Functional Blocks and the relationships among them depicted in this diagram represent the CORBASec multiple 
security domain, multiple ORB interceptor services, and application invoked architecture. 
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BASec [like Enterprise Java Beans 
(EJB)] supports container-based secu- 
rity, in which a rich array of security ser- 
vices enforce security transparently, al- 
lowing the developer to concentrate on 
building the application rather than the 
supporting infrastructure. The para- 
digm shift away from a security API re- 
sults in security software that is con- 
trolled and managed at the ORB 
interceptor layer and is less prone to 
programming error. 

Within the computer-security disci- 
pline there is much talk about role- 
based security. In the distributed- 
computer-security world, CORBASec, 
unlike other distributed role-based se- 
curity models (e.g., EJB security), de- 
fines security domains to allow parti- 
tioning of enterprise systems that need 
to secure large numbers of resources. 
The NPSS team needed a design suit- 
able for the enterprise systems and 
therefore, we chose to use the COR- 
BASec approach. The choice of a de- 
sign that supports multiple security do- 
mains has enabled the NPSS team to 
develop a highly scalable architecture 
that allows room for growth. 

The CORBASec test bed is designed to 
provide peer (client and server) role- 


based authorized security at the CORBA 
object (interface, method, and variable) 
levels. For the purposes of discussion, 
this article focuses on the functionality of 
the peer client: The CORBASec client 
authorization architecture (role-based 
design) allows each client access to a sim- 
ulation object’s functionality based on a 
run-time comparison of the clients’ 
granted roles and credentials against the 
required rights of the object. The test 
bed uses the HSS administration tool to 
configure three NPSS client user roles: 
developer, general user, and restricted 
user. Initially, each client role-based user 
is checked for the proper security do- 
main access. Developers are granted full 
access to the private and public simula- 
tion object variables and methods as well 
as access to methods unique to program- 
mers. General users are granted full ac- 
cess to all private and public simulation 
object variables and methods (except 
developer-only methods) . Restricted 
users are granted only public access. If 
necessary, various other role-based 
configurations can be developed with 
the CORBASec test bed and its HSS 
administration tool. 

In the figure, the two ovals labeled 
Site 1 and Site 2 represent separate 


aerospace propulsion company net- 
work sites. The two ovals labeled Secu- 
rity Domain 1 and Security Domain 2 
contain CORBA servers shown as boxes 
labeled HSS Manager, Interpreter, Sim- 
ulation, and SecBuddy. The dashed ar- 
rows depict the flows of public infor- 
mation among these servers. The solid 
arrows depict the flows of delegated 
private information among these 
servers. The boxes outside the ovals in 
the figure represent CORBA clients. 
The HSS Manager at each site authen- 
ticates clients for access to specific se- 
curity domains. 

The test bed is expected to demon- 
strate NPSS CORBASec-specific policy 
functionality, confirm adequate perfor- 
mance, and validate the required Inter- 
net configuration in a distributed 
collaborative aerospace propulsion envi- 
ronment. 

This work was done by Tammy M. Blaser of 
Glenn Research Center. Further informa- 
tion is contained in a TSP (see page 1 ). 

Inquiries concerning rights for the commer- 
cial use of this invention should be addressed 
to NASA Glenn Research Center, Commercial 
Technology Office, Attn: Steve Fedor, Mail 
Stop 4-8, 21000 Brookpark Road, Cleveland 
Ohio 44135. Refer to LEW-1 7214. 
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